經過統計的疲勞轟炸，今天來聊一點輕鬆的內容吧。

Netflix 是一間勇於嘗試、大膽做實驗的公司，無論是廣告、付款方式、給客戶的訊息（例如 email）、聲音及影像的品質，他們都會用不同的方法、測試各種假設，以取得最好的結果。

除了 Netflix，各大科技公司都會使用 A/B testing 以幫助決策。但是，每天都有數百萬人使用的產品，要如何快速迭代、執行實驗呢？如果有參與過產品開發、部署及上線的人都知道，即便只是一個功能改進，都需要前後端一起配合、QA 需要分別在測試環境和實際上線環境，是一個相當浩大的工程。倘若 Netflix 同時間想要測試不只一種功能，且每個功能又不只一種版本，想到就昏頭了，一個如此多人使用的產品，要如何在同個時間點有效率地執行不同實驗呢？

讓我們來看看另一間大公司 Uber 是如何有效率地處理這個問題吧！

Uber 的舊系統 - Morpheus

以前 Uber 是用 Morpheus 這個實驗平台來執行 A/B testing，但是這個舊的實驗系統有很多問題，部署不易、難以維護、無法讓實驗者確定結果是正確無誤的。然而，一個好的實驗系統應該可以讓實驗者確保資料是正確的、快速地執行實驗，尤其是在 Uber 這種需要執行複雜又多樣實驗的公司，實驗結果往往讓人存疑，需要人為勞心勞力地檢查，耗費時間跟人力成本。

來舉一個具體的例子，來看看真實執行 A/B testing 的實驗組別可能會多複雜。

今天 Uber 想要測試什麼樣顏色（藍或黑）的按鈕比較適合，因此決定做 A/B testing 測試。

上圖為 Morpheus 的設定方式，即便只是一個簡單的小改動——更改按鈕顏色，若每次要新增一個組別，無論是在 option #1（if/else）需要多輸入一個條件，或是 option #2 手動更改 BUTTON_COLOR，都需要人為更改。且因為有改動程式碼本身，要配合產品上線時間。

甚至，Uber 不會只想要簡單分成兩組，他們希望在每一個地區測試不同組別，分組方式如下所示：

• California
  • 藍色
  • 黑色
• Washington
  • 藍色
  • 黑色
• Texas
  • 藍色：40% 的使用者
  • 黑色：60% 的使用者

但是，在上線的 app 中，要如何知道使用者在什麼地區呢？在 Texas 出於未知原因，使用者甚至不是 50/50 的分組方式。另外，如果資料科學家發現黑色按鈕的成效不好，臨時想要改成藍色和綠色的測試，是不是又要等下次的產品更版時間？

近幾年來 feature flagging（就是指如上面範例的按鈕顏色） 在 Uber 變成常態，需要手機 apps 和後端結合使用。Morpheus 如上述，難以讓研究者在手機 app 上進行測試。一個 app 的發布時程通常需要等兩到四週，無法快速迭代實驗，得到結果的速度相當緩慢。

新系統需要的功能

1. 簡單執行複雜的邏輯：實驗往往需要很複雜的邏輯判斷，何時、何地執行實驗，每一組要分派多少比例的使用者，不一定永遠都是 50/50 分組，有時甚至需要在實驗中途更改實驗設定。
2. 輕鬆設定實驗組別：每一個實驗中使用者的分類方式可能都不同，可能取決於實驗、feature flags、網路速度；有時相同的特徵需要在不同的地區、apps、裝置等等獨立測試。
3. 實驗要能夠在手機 app、網頁版和後端執行。

New Platform

登登登登，由於種種舊平台的實驗執行困難，Uber 決定直接改版，如下圖所示：

由上圖可以清楚地看到，跟之前的架構比起來，這個平台讓實驗者只需要在後端進行設定，即可輕鬆優雅地置換按鈕顏色，無需更改 app 本身的程式碼，因此也無需等到 app 更版才可以測試。倘若因為用戶的網路問題，無法成功回傳資料，也會直接設定成預設顏色。

這個新平台可以完美體驗 Uber 覺得執行實驗最重要的三件事。

執行實驗最重要的三件事

Randomization

在指派組別時，隨機性是最重要的事。
在這個新平台中，每個實驗會有獨特的 experiment key，以這個 key 當作 salt、hash 用戶的 identifiers，再取除以 100 的餘數當作 unit bucket。

簡而言之，用戶會被分成 100 組，且每次實驗的 key 不同，用戶每次被分到的組也會不同。並且只要重複執行相同實驗的 key，每次用戶的分組都會相同，可以得到 replicable 的結果。

Treatment groups

當每個用戶都有自己的組別（0-99）後，再用樹狀結構來分實驗的組，每一個 node 會是連續的號碼，這樣有助於更複雜的實驗設計。

舉一個具體的例子，今天資料科學家想要將實驗分成控制組（control group: 0-49）和實驗組（treatment group: 50-99）。在執行實驗一段時間後，他們突然好奇實驗組如果再加一個 feature，結果會不會不同。

藉由這種樹狀架構，他們可以輕鬆地將 treatment 組再分成三組：treatment 1 (50-59)、treatment 2 (60-69) 和 treatment 3 (70-99)。

Treatment plan

在決定每一個 context 下要做什麼實驗時，例如不同地區、裝置、或其他資訊，只需要依照用戶的組別，把測試內容寫在後端，前端就會自動渲染。且可以一次執行多種實驗，在各種裝置、地區等快速測試相同的 feature，不會互相影響。

if unit in control_group_list:
    if context.city == "San Francisco":
        button_color = "green"
elif unit in treatment_group_list:
    if context.city == "San Francisco":
        button_color = "black"

Logs

最後，為了記錄正確的資料，新平台也提供穩固的送 logs 系統，保證實驗資料的正確性。

好的，以上就是 Uber 在實際執行 A/B testing 遇到的困境，以及他們的解決方法。

我覺得這個平台系統滿值得需要執行實驗的人參考的，尤其是樹狀分組和從後端控制實驗內容，可以輕鬆優雅地執行複雜實驗。

謝謝讀到最後的你，如果喜歡這系列，別忘了按下喜歡和訂閱，才不會錯過最新更新。
也歡迎到我的 medium 逛逛！

Reference:

• Supercharging a/B Testing at Uber: https://www.uber.com/blog/supercharging-a-b-testing-at-uber/